1. Field of the Invention
The present invention relates to computer systems. More specifically, the present invention relates to identifying and executing locked read and write regions in programming languages that offer synchronization but which do not offer explicit means to distinguish between such regions.
2. Description of the Related Art
Many modem operating systems allow for the simultaneous execution of multiple processes within an application and these executing processes are typically referred to as threads. As will be apparent to those of skill in the art, in single processor systems threads in fact are not executed simultaneously, but instead share the processor between themselves and other applications being executed on the processor, but this sharing of the processor is largely transparent to users and to programmers who treat it as a logical simultaneity, and is not generally a consideration to the discussion herein. Thus, the discussion herein uses the term simultaneously in its logical sense rather than its literal sense and the present invention can function on single processor or multiprocessor computer systems.
An application may have many threads executing simultaneously and these threads share the resources, particularly the memory space, of the application. Thus, care must be taken by the programmer of the application to ensure that resource contention issues do not result in unexpected or undesired behaviors by their application. In particular, circumstances wherein one thread of an application is writing to an address in memory while another thread is reading from that same address must be avoided, otherwise indeterminate and/or incorrect results and behaviors may occur.
Many programming languages which provide threads also provide memory locking mechanisms to prevent such memory state uncertainties. In the Java™ programming language, the synchronized keyword provides a locking scheme that gives controlled access to sections of the Java code. Java is a trademark of Sun Microsystems, Inc. The synchronized keyword can be applied to methods or blocks of code in a method and operates such that the first time a thread enters the synchronized code, a lock is obtained against a particular Java object. As long as that thread holds the lock on that object, no other thread can obtain a lock on the same object and thus no other thread can enter a synchronized method or block using the same object. The synchronized keyword provides the means for a programmer to give the thread holding the lock a consistent view of the contents of one or more memory addresses by preventing other threads from executing code that may change the memory addresses in question before the lock is released.
While locking mechanisms such as Java's synchronized keyword are well known, they can suffer from disadvantages. For example, Java's synchronized keyword does not differentiate between synchronized methods which read from fields and synchronized methods which write to fields. As will be apparent, a thread executing synchronized code which merely reads from fields need not prevent other threads from reading from those same fields, but does need to prevent any threads which wish to write to those fields from doing so while reads are occurring. Conversely, a thread executing synchronized code which writes to a field must prevent any other thread from writing to that field and any other thread from reading from that field until the first thread has exited that synchronized code.
As Java's synchronized mechanism does not make a differentiation between synchronized code that merely reads from fields versus code that writes to fields, threads can be blocked from executing which, in fact, need not be blocked and execution of applications are thus less efficient than might otherwise be the case as threads can be needlessly waiting to be allowed to execute. Further, it is common practice to synchronize entire methods in Java which often causes synchronization to be in effect on instructions that are neither read nor write fields. Thus, often locks are invoked more often than is necessary during execution of the program and have longer durations than necessary.
The problems with Java's synchronized keyword are known and attempts to analyze the performance impact of these problems have previously been made. One such analysis is described in, “Detecting Read-Only Methods in Java”, Jeff Bogda, LCR 2000, May 25-27, 2000, pages 143-154.
Bogda performs a static, whole program analysis, wherein the complete call graph is known, to examine Java synchronized methods. Bogda determines if a method is a read method or a write method. As a result of his analysis, Bogda has found that approximately 31% of methods in the SUN™ JDK 1.2 core libraries are read-only methods. Bogda's findings show that an improvement to thread performance in Java could be achieved with an improved synchronized mechanism. However, Bogda does not teach how to identify and implement locks for read methods and write methods when performing less than a static whole program analysis. Further, Bogda only considers the read or write status of entire methods designated as being synchronized.
There is needed a method for identifying and executing synchronized read and write regions in programming languages that offer synchronization but which do not offer programmers means to explicitly distinguish between such regions.